In contemporary network systems such as network storage systems, a system issue, such as a problem with a monitored resource (e.g., a hard disk component), is typically identified via a system logging mechanism. In general, an event monitor notifies a targeted audience (one or more users, referred to hereinafter as simply a “user”) of a detected problem with a system resource, typically by sending an email message. The user needs to receive and read the email to recognize that there is an issue. The user needs to be reasonably skilled to interpret the message, because the log information is exposed to the user basically verbatim, and contains only low-level system information.
More particularly, a user responsible for the system reads the log information to determine that there is an issue with a resource. Then, once recognized by a user, the user needs to manually correlate the part of the system that is directly affected by the event (e.g., a lost connection between a storage system and an attached server) to determine the impact of the event, and decide a level of urgency to apply to addressing the issue. For example, the message may indicate that a hard disk is not functioning properly, whereby the user then needs to determine how serious the problem is.
Currently, a user accomplishes this by manually running a number of queries to the network (e.g., storage) system to determine how the system resource is being used and by what entity or entities, and then decides what further steps to take and when to take them. For example, if the disk is not being used by any important applications and it is night time, then any corrective action may wait until the next morning. Conversely, if the disk is being used by a server running an important application such as payroll, the corrective action may need to be taken immediately. This manual approach is both time consuming and potentially error prone.